Optical network control planes provide automatic allocation of network resources in an end-to-end manner. Exemplary control planes may include Automatically Switched Optical Network (ASON) as defined in G.8080/Y.1304, Architecture for the automatically switched optical network (ASON), the contents of which are herein incorporated by reference; Generalized Multi-Protocol Label Switching (GMPLS) Architecture as defined in Request for Comments (RFC): 3945 and the like, the contents of which are herein incorporated by reference; Optical Signaling and Routing Protocol (OSRP) from Ciena Corporation which is an optical signaling and routing protocol similar to PNNI (Private Network-to-Network Interface) and MPLS; or any other type control plane for controlling network elements at one or more layers, and establishing connections there between. As described herein, these control planes may be referred to as control planes as they deal with routing signals at Layers 0, 1, and 2, i.e., photonic signals, time division multiplexing (TDM) signals such as, for example, Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN), Ethernet, MPLS, and the like. Control planes are configured to establish end-to-end signaled connections such as sub-network connections (SNCs) in ASON or OSRP and label switched paths (LSPs) in GMPLS and MPLS. Control planes use the available paths to route the services and program the underlying hardware accordingly.
In operation, an optical network operating a control plane includes interconnected network elements that exchange information with one another via control plane signaling. As such, each network element has a routing database with up-to-date information about the network, e.g., topology, bandwidth utilization, etc., that enables path computation at a connection's source node (i.e., an originating node). Once a path is computed for the connection, the source or originating node performs call connection management to set up the connection in the network. Conventionally, call connection management is solely triggered from the originating node, i.e., the originating node computes the path and signals the path in the network, and upon a failure, the originating node redials the connection. The fact that call connection management is only handled by the originating node is restrictive making call connection user operations cumbersome especially those which require moving a connection away from its working path, or network management operations performed on the basis of link/line state or link/line utilization. For example, user operations can include, without limitation, Manual Switch to Protect, Regroom, Manual Revert and Configure, etc. With the conventional techniques, performing such user operations requires operators to search for a related call connection when decisions are made based on link/line utilization or state. This is cumbersome and impractical. Thus, it would be advantageous to support non-originating node call connection management.